Night Owl 6/Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso/036a/os2info.zip/REPORT.OS2

Text File | 1991-05-20 | 22KB | 442 lines

Report Date: Wed May 27 15:38:26 1987
----------
TITLE: IBM seminar report

This information is extracted from my trip report on the IBM
seminar last week.  It is subject to the usual caveats in that it
may all be lies - I'm just reporting from memory what IBM told
me.  In particular, anything that looks like a direct quotation of
IBM people should be considered in light of the fact that we used
cold bottles of Becks each evening for memory refresh.  Don't anyone
sue me for quoting them out of context.  All conclusions and opinions
are solely my fault - if you don't like them go buy a Mac!  This
is *not* a review as there was very little hands-on that was not
supervised by IBM folk.

Enjoy, Matt
====================================================================

Trip Report: IBM Technical Seminar, PS/2 and OS/2
             May 18-22, 1987

By:          Matt Trask
             May 26, 1987


Overview

    Last week I attended two of the three sessions
    provided by IBM for independent developers.  I have
    summarized the presentation in three sections - PS/2,
    OS/2, and future directions.

    This is not necessarily a review as there was very little
    hands-on.  Most of this report is based on information
    provided by IBM engineers and product managers.

OS/2

    The OS/2 presentation was opened with a presentation of
    IBM's System Application Architecture (SAA) strategy.  For
    anyone that is not familiar, SAA is a plan of
    connectivity, application portability, and a common
    user interface that is intended to give business users
    that fuzzy blue feeling that can only occur when all of
    your machines are IBM and running IBM supported software.
    This plan spans from the Model 50 up to the largest IBM
    mainframes and specifies details such as the supported
    programming languages.  All comments that IBM made about
    OS/2 and much of the PS/2 remarks were phrased in terms of
    SAA compatibility.

    OS/2 provides three programming models: Compatible, Family
    API, and OS/2 API.  The simplest of the three is
    Compatible - it allows many existing PC applications to
    execute in a "DOS Box".  There is no protection for the
    system from such programs and their performance will
    probably be degraded by running in a multitasking
    environment.  This is provided "only as a migration path".

    The Family API programming model is a limited subset of
    OS/2's full capabilities.  Programs that are built with
    the Family API assumptions can run unmodified under DOS
    3.x as well as OS/2.  For many applications this is the
    best strategy for creating a product to fit the largest
    markets, especially products like language translators
    that don't need to use any Gee Whiz features like
    graphics.

    The full OS/2 API includes tasking, IPC, and advanced
    timer services, as well as Family API services such as
    memory allocation and file I/O.  This model provides full
    hardware protection for the system.

    The system is still configured with CONFIG.SYS but many
    new commands have been added.  PROTSHELL is the PM
    equivalent of the SHELL command.  RUN is used to start
    background programs such as mail daemons. PROTECTONLY and
    RMSIZE control the existence and size of the "DOS box".
    MAXWAIT sets a timeout limit to control process starvation.
    A starving process will have its priority raised
    temporarily on a MAXWAIT timeout to guarantee CPU cycles.
    TIMESLICE can be use to tune the quantum length.  MEMMAN
    commands such as SWAP/NOSWAP and MOVE/NOMOVE control
    whether tasks can be swapped to disk and whether the OS
    can rearrange segments in memory to use its resources
    efficiently.  SWAPPATH defines the file resource that will
    be used for virtual memory (Caveat: swapper will fill a
    disk until it fails if you overload it!).  The TRACE and
    TRACEBUF commands control the size and use of a ring
    buffer to store OS events for later analysis.  This buffer
    and its contents are not documented - intended for IBM use
    in troubleshooting end user problems.

    Device Drivers under OS/2 are quite different from DOS
    device drivers.  They run at CPL=0 thus allowing the
    programmer to have the run of the system.  An OS/2 device
    driver is bimodal - it must be able to run in real or
    protected mode without distinguishing between the two.
    For example, a driver could start an I/O in protected mode
    and go to sleep.  The completion interrupt could occur
    after the kernal swaps to real mode to run the "DOS box".
    Drivers, like applications, are dynamically linked at load
    time.

    Device drivers are officially *not* written in C.  There
    is no guarantee of adequate stack resources when a driver
    is executing.  The IBM engineers were very uncomfortable
    with the thought of C drivers, suggesting that subsystems
    were the place for C code.

    The parts of a driver are Strategy Routine (real code, not
    a pointer-saver), Interrupt Routine (this is the ISR as in
    Unix, not just a name as in DOS), Timer Handler (used for
    device timeouts), and a software interrupt handler that is
    used only in real mode.  A set of OS functions known as
    DevHlp services are available to drivers - these functions
    can be used for limited file handling, memory allocation,
    pointer normalization (to remove mode dependencies), etc.

    IOCTL is no longer an optional function - it must be
    supported in all drivers.  There is a new field in the
    attribute word that defines the minimum version of the OS
    required to run the driver.  Monitors are supported as a
    way for user level applications to examine the data stream
    as it passes through a driver.  This function is
    cooperative in nature and must be designed into the driver
    itself.

    A new class of program called "Application Special Purpose
    I/O Routine", or more commonly, IOPL, allows user level
    apps to access I/O ports that would not normally be
    available at CPL=3.  The IOPL runs at CPL=2 thus allowing
    an easy path to the hardware.

    Multitasking is the main new feature of OS/2.  It is based
    on the model of sessions (up to 12 per machine) that
    contain processes that have at least one thread executing
    in them.  Processes can be thought of as the "owners" of
    allocated memory, file handles, etc., while threads share
    common access to data within a process and are the actual
    code of a process.

    OS/2 uses priority based execution with three levels of
    task priorities: time critical, regular, and idle.  Idle
    tasks are run only in the CPU's idle time while time
    critical tasks are run whenever needed.  Most programs
    fall into the regular category.  Regular tasks are
    protected from starvation by the MAXWAIT option in
    CONFIG.SYS.

    Subsystem is the model used for O/S extensability.  This
    is roughly comparable to the way that DOS device drivers
    are currently used.  Currently the keyboard, mouse, and
    video are implemented as subsystems.  This eases
    replaceability of this code.  In the Extended Edition, the
    Comms and Database Managers are also subsystems.  This
    code runs at the caller's CPL.

    The current OS/2 filesystem is the DOS filesystem
    including its 32Mb limits.  This filesystem is replaceable
    but the IBM reps wouldn't say when or how.

    The big "gotcha" in OS/2 is the size of the registers
    stored in a task switch.  Because it uses a 286 compatible
    TSS when running on an 80386, only the lower 16 bits of
    the registers are preserved.  If an application uses the
    32 bit forms of the CPU's registers, the high order 16
    bits will be trashed by other applications that do
    likewise.  This same problem will occur with other 8086
    multitaskers such as Double DOS and Multilink.


PS/2

    Option boards and configuration - there is a 16-bit
    identification register on each option board.  IBM
    reserves the first 32K IDs for their own use; the other
    32K IDs are available to outside developers and are
    coordinated by IBM (Hayward Rigsby 305/241-5455).  Cards
    that clone the ones available from IBM can use the same ID
    numbers if "the boards will pass power on test and
    configuration".

    Bus slots are numbered and individually addressable
    allowing option boards to optionally "answerback" when
    selected.  Port 96H is used to select a card by its ID
    number for configuration and setup.  Ports 100-107H are
    used to access POS registers (Program Option Select) on
    the option card.  There is a sleep bit defined in these
    registers for all option boards - it is used by the OS to
    manage port conflicts by sleeping boards that are not in
    use.  There is also a channel check bit on each board that
    can be interrogated by the OS to determine who caused the
    fault.  The bus timeout mechanism ensures that ailing or
    offending boards can be controlled by the OS.

    The VGA supports all EGA/CGA/Mono modes to provide
    backward compatibility plus 6 new modes.  All 200 line
    modes are scan doubled to 400 lines to give better quality
    display.  All of the VGA's registers are readable which
    eases virtualization in a multitasking OS.  All video
    modes are available on all monitors - gray scale summing
    is done on monochrome monitors.

    8514/A Advanced Video Board - A high end graphics product
    that was featured at the seminar.  It uses the extended
    video slot of the Micro Channel to intercept control from
    the VGA.  Capable of 1024x768 and 640x480 pels with 256
    colors from palette of 256K.  It is capable of modifying
    64 bits in a single 140ns cycle.  The only interface
    provided by IBM is a high level application interface with
    with verbs such as DRAW, FILL, BLT, MIX, MASK, and
    SCISSOR.  IBM has chosen to make the lower level interface
    such as registers and modes proprietary to prevent future
    compatibility problems ("If we let you use the modes,
    we'll have to support them in future products whether we
    like them or not ... ").  Unused video RAM is used as a
    font cache, characters are BLTed onto the screen.

    The PS/2 announcements included a new lower cost baseband
    PC network and PS/2 versions of all existing network
    products.  The networks are not yet supported under OS/2
    but the IBM folks would only say "networks are a very
    strategic product" with a knowing look.

    The bus performs multidevice arbitration for up to 15
    devices plus the CPU using 6 bus lines.  An ARB cycle can
    be requested by any device and will be resolved within
    300ns.  There is a programmable fairness algorithm and the
    central arbiter can be inhibited via an I/O port.  DRAM
    refresh cycles are hidden within ARB cycles.  A device
    that is granted bus mastership can assert the BURST line
    and will be guaranteed a minimum of 7.8 microseconds
    (about 128 bytes).  The bus cannot be seized permanently
    by a temporary bus master because the watchdog timer (and
    other devices at ports below 100H) is not available on the
    bus, guaranteeing that the main CPU will always regain
    control.  The bus timeout and watchdog mechanisms generate
    NMIs that cannot be masked by port 70H.

    There is a facility for RAM defect relocation that can be
    used to remap defective memory out of the linear address
    space.  This mapping has a 16K granularity on any 16K
    boundary.  It may be possible to use this to emulate LIM
    type bankswitching, but it may require disabling the 1Mb
    of planar RAM before use.  The Model 30 has a 64K memory
    mapping granularity.

    ABIOS - The Advanced BIOS is contained in ROM in the PS/2
    systems.  It is primarily intended for OS use rather than
    application use.  There is no ABIOS in AT machines so OS/2
    is obviously not dependent on it.  This BIOS can be
    replaced by disk and RAM based ABIOS code if desired.  The
    PC compatible BIOS is now referred to as CBIOS.  ABIOS has
    a call-based interface rather than the PC's
    interrupt-based interface.  It is fully bimodal so it can
    be used in real or protected mode.  There is a new BIOS
    data area defined in high memory that occupies one K of
    RAM.

    System security is provided by a password of up to 7
    characters that is stored in battery backed CMOS RAM.  The
    keylock is only used to prevent physical access to the
    system unit.  The password is "unlocked" during POST and
    "relocked" before booting the OS.  "There is a back door
    for IBM service people."  There are three security modes:
    power on security will not allow the machine to boot,
    including the floppy disk; server security allows the
    machine to boot and execute its AUTOEXEC.BAT but the
    keyboard is locked until the password is entered.  A more
    temporary form of security is provided by an program that
    locks the keyboard only until the password is entered.

    The interrupt controller (PIC) is implemented in a VLSI
    gate array (along with most other support functions).  It
    is operated in level-sensitive mode rather than
    edge-triggered as in the PC.  In fact, any attempt to
    reprogram it into edge-triggered mode will be trapped and
    converted to equivalent level-sensitive commands.
    Interrupt sharing protocol is now an integral part of the
    system rather than an afterthought (see the AT 339 TRM).
    This allows more than one adapter to share a single
    interrupt level.  Because of this possibility, programmers
    should avoid doing an EOI at the start of an ISR - EOI
    should only be done after resetting the IRQ latch (if
    any).

    Because OS/2 operates by switching between real and
    protected mode, the system reset function that was
    implemented with Int 15h on the AT has been improved by
    the addition of a "hot" shutdown method that is much
    faster than the 8042 (IBM claims 10X faster).  The
    undocumented 80286 SHUTDOWN instruction (opcode 0F 05)
    still works as expected causing a system reboot.

    Adapter cards can still install their own BIOS code during
    POST via the "ROM scan" method.  There may be problems
    with this in that the BIOS can put boards to sleep in case
    of port or interrupt conflicts.  IBM recommended therefore
    that initialisation be done under software control rather
    than by ROM scan.

    The DMA controller is also implemented as custom VLSI.  It
    provides a compatible 8237 at the expected ports, but adds
    additional functionality such as making all registers
    readable and an orthogonal interface that is accessed
    through ports 18h and 1Ah.  Although all operations at
    these ports are supposed to "shadow" to the compatible
    ports, a quick hands-on showed that this was not
    necessarily true.  All channels support 8 or 16 bit
    transfers.  Memory-to-memory transfers are no longer
    supported.  The DMA controller covers the full 24-bit
    address space with no artificial 64K boundaries - there is
    a limit of 16 megabytes that may be a problem on 386 based
    systems.  Also, there are two "virtual" DMA channels that
    can be mapped to various channels and programmed for
    different ARB levels.

    The parallel port on the motherboard is bidirectional and
    is used by the IBM Data Migration Facility to port code
    and data from PC family machines.  The DMF provides a
    Centronics-to-DB25 adapter and software that will transmit
    files out a PC's printer port.

    The Model 60 and 80 machines can use an ESDI disk adapter
    with 70 and 115 megabyte disks as well as the ST412/506
    adapter with 44 megabyte disks.  The ESDI disks
    automatically park their heads on power down to prevent
    data loss.  The ESDI controller supports 32-bit data
    transfers as well as 8- and 16-bit.  All PS/2 machines are
    provided with disk cache software to enhance system
    throughput.  The ESDI adapter may possibly be attributed
    to Adaptec.

    Protection from radio frequency interference (EMC is the
    buzzword at IBM) was a major design issue for the Micro
    Channel and PS/2 machines because of the higher bus speeds
    that are supported.  Every other pin on the bus is either
    a power or ground so no signal is more than one pin away
    from one, enhancing noise immunity.  The Option Retaining
    Bracket (ORB) was used as a ground return on most PC bus
    adapter cards - this is specifically forbidden on the
    Micro Channel because it will circumvent the designed in
    protections from radiation.

    Any adapter can assert the PREEMPT line on the bus to
    become a bus master.  There is a programmable fairness
    algorithm that can be used to tune bus arbitration between
    masters.  A master can only hold the bus (maximum) until
    the watchdog timer causes an NMI on the main CPU, thus
    returning control to the CPU.  The timer is not accessible
    over the bus and is not maskable with the normal NMI mask
    so the system CPU is guaranteed to always regain control
    from a "bus hog".  There is a hardware bus timeout that is
    used to detect option card failures that would normally
    hang the system.  A BIOS call can be used to determine
    what slot is occupied by any given adapter card.  The bus
    was designed to use 150ns RAMs on adapter cards through a
    decode headstart mechanism in the bus cycle.  There is
    also a matched memory protocol (MMP) and fast cycle
    request available to support faster memory.  An auxiliary
    video connector on one of the slots allows add-in video
    boards to intercept VGA signals for their own use before
    thay get to the external connector - this allows enhanced
    video cards such as the 8514/A to use the VGA for
    compatibility in addition to adding higher resolution.
    The audio channel on the bus is intended for card-to-card
    use.

    The PS/2 mouse appears to be a Microsoft mouse in that it
    has 2 buttons, a 9-pin Hosiden connector, and the
    ball/lock ring are identical to Microsoft's.  The physical
    form factor of the mouse is slightly larger.  I could see
    no evidence of the Microsoft InPort chip on the Model 50,
    60, or 80 motherboards but that does not preclude its
    inclusion in the custom gate arrays.  (One of the IBM
    buzzwords during the presentation was "high IBM content of
    the system".)

    When one of the seminar attendees asked about licensing
    the Micro Channel for clone use, the IBM rep gave a very
    circular answer something to the effect that it is the
    responsibility for all manufacturers to honor the patents
    and copyrights of others.  He also said that it is IBM's
    policy to not license patents or copyrights.  My
    interpretation is that IBM will attempt to prevent bus
    cloning.  Contact Henry Hall at IBM's Purchase, NY
    facility regarding intellectual properties issues.

    There are several "gotchas" in the system design that were
    brought out at the seminar.  The first one had to do with
    I/O and prefetch queues, all back-to-back I/Os should be
    separated by a JMP $+2.  Another example was given on a
    386 system,

             out 20h, 20h        ; EOI
             jmp $+2
             sti

    would allow the EOI to occur before interrupts are
    reenabled.  All accesses to port 70h should be followed by
    a read or write to port 71h, even on NMI mask accesses
    that normally would not need this.  Failure to do so could
    cause premature discharge of the CMOS backup battery.
    There is a new BIOS data area defined at the top of memory.
    It is the developers responsibility to not overwrite this
    1K area (eg- with memory tests that attempt to write all
    locations).  The CPU's LOCK pin is not connected to the
    bus - this means that the software LOCK prefix is not
    meaningful.  The BURST line can be used as a bus lock when
    needed.


Futures of OS/2

    OS/2, The Extended Edition, was covered in some depth at
    the end of the seminar.  This version is due out sometime
    in 1988.  It includes a Graphical User Interface based on
    Microsoft Windows as well as an integrated Communication
    Manager and Database Manager.

    The Communication Manager is not particularly useful for
    communication as done by most current PC users.  Its main
    features involved connectivity to larger IBM systems with
    just a few gestures at PC-to-PC comms.  This fits in well
    with the SAA concept but gets in the way of the typical PC
    communicator.

    Likewise for the integrated Database Manager - it provides
    an environment for data management that is very similar to
    larger IBM systems.  However, it ignores PC standards such
    as Dbase II/III compatibility and newer technologies such
    as fulltext inverted databases which are starting to
    become important now that optical media are being used on
    PCs.

    Both of these OS extensions use the Subsytem abstraction
    as a way to seamlessly enhance the base OS.  The extended
    version does not run on ATs, only on PS/2 systems.

    <END>